home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
ietf
/
dhc
/
dhc-minutes-93mar.txt
< prev
next >
Wrap
Text File
|
1993-04-28
|
4KB
|
95 lines
CURRENT_MEETING_REPORT_
Reported by Ralph Droms/Bucknell
Minutes of the Dynamic Host Configuration Working Group (DHC)
The Working Group discussed the interface between DHCP and the Domain
Name System (DNS). DHCP needs an interface that can allow dynamic
updates to DNS entries in response to dynamic allocation of DNS names to
DHCP clients. Rob Austein explained that the DNS Working Group is
currently developing such an interface to DNS that considers the needs
of DHCP.
The Working Group discussed the possible use of SNMP with DHCP. SNMP may
be useful as a ``second-level'' bootstrap mechanism to transmit
additional configuration parameters to a client. SNMP is not likely to
be as useful as an implementation-specific interface for server
management. SNMP is an interesting candidate for the server-server
protocol, as it may provide the semantics and data representation tools
required for exchange of DHCP binding information between servers.
The Working Group discovered a technical problem with the current
definition of the `chaddr' field, which provides for use of `chaddr' as
either a hardware address or other unique identifier. As the `chaddr'
value must be used to return DHCP reply messages to the client, that
field will be reserved for use strictly as a hardware address, and the
client will be required to supply a unique identifier in a `client
identifier' option. This identifier will be a typed value with the same
structure as defined for the `chaddr' field.
Mike Carney and Jon Dreyer submitted a new definition for encapsulating
vendor-specific options that the Working Group accepted with minor
modifications. In the accepted definition, the `vendor- specific
information' option will include an initial value that identifies how to
interpret the contents of the option, and other DHCP options, encoded in
the same format as the current variable- length DHCP options. The
initial identifying values will be centrally administered to avoid
conflicts. One identifying value will be reserved for local use.
The mechanism for determining the parameters returned to a particular
client was discussed at length. The focal points of the discussion were
the ways in which a client can identify its characteristics (`client
type' option) and the rules by which a server can use those
characteristics to choose the information to be returned to a host. No
conclusion was reached at the meeting; an interim solution will be
incorporated into the DHCP specification Internet-Draft to allow the
protocol to move forward to Proposed Standard.
Attendees
Kannan Alagappan kannan@dsmail.lkg.dec.com
Steve Alexander stevea@lachman.com
1
Philip Almquist almquist@jessica.stanford.edu
Robert Austein sra@epilogue.com
John Boatright bryan_boatright@ksc.nasa.gov
Gregory Bruell gob@wellfleet.com
Ralph Droms droms@bucknell.edu
Robert Gilligan gilligan@Eng.Sun.Com
Richard Harris rharris@atc.boeing.com
John Hascall john@iastate.edu
Roland Hedberg Roland.Hedberg@rc.tudelft.nl
Ronald Jacoby rj@sgi.com
Scott Kaplan scott@wco.ftp.com
Frank Kastenholz kasten@ftp.com
Mark Kepke mak@fc.hp.com
Andrew Knutsen andrewk@sco.com
Lakshman Krishnamurthy lakashman@ms.uky.edu
Yu-Lin Lu yulin@hpinddu.cup.hp.com
Paul Lustgraaf grpjl@iastate.edu
Kent Malave kent@bach.austin.ibm.com
Glenn Mansfield glenn@aic.co.jp
Evan McGinnis bem@3com.com
William Nowicki nowicki@legato.com
William Owens owens@acsu.buffalo.edu
Charles Perkins perk@watson.ibm.com
Steven Richardson sjr@merit.edu
Shawn Routhier sar@epilogue.com
Jon Saperia saperia@lkg.dec.com
Chris Shaw cshaw@banyan.com
Marek Tomaszewski marek@net.com
Walter Wimer walter.wimer@andrew.cmu.edu
2